Method and system for a security model for a computing device

ABSTRACT

A system, method and computer-readable media are disclosed for a security model and mode of enforcement in a graphics subsystem in a computing device. A uniform, streamlined, and flexible procedure for creating objects that contain their own security policies and are placed in protection domains when they are instantiated based on their specific security needs is described. A process boundary is utilized as the primary security or protection boundary for enforcing the security model. The security model takes advantage of the fact that most object models allow objects to have interfaces. An object&#39;s interfaces are used to determine what caller objects are capable of accessing. Thus, there is a mapping of an object&#39;s capabilities to interfaces. An object determines what a caller object is entitled to based on the investigation by the caller object and of what the caller object&#39;s knowledge of the object&#39;s interface. The caller&#39;s investigation determines what other aspects of the object the caller is entitled to. The method aspect of the invention comprises an interface of a target object receiving a call from an external object which is aware of the existence of the interface. At the target object, it is determined whether the external object has access to other interfaces of the target object based on the first call. Access is granted to other interfaces based on this determination.

PRIORITY CLAIM

The present invention claims priority to U.S. Provisional PatentApplication No. 60/543,108 filed on Feb. 9, 2004, the contents of whichare incorporated herein by reference.

RELATED APPLICATIONS

The present application relates to the following applications: (1)Attorney Docket No. 4001.Palm.PSI entitled “A System and Method ofFormat Negotiation in a Computing Device”; (2) Attorney Docket No.4002.Palm.PSI entitled “A System and Graphics Subsystem for a ComputingDevice”; and (3) Attorney Docket 4004.Palm.PSI entitled “A System andMethod of Managing Connections with an Available Network”, each of whichare filed on the same day as the present application, the contents ofeach Application are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to operating system software.More particularly, the invention relates to software for implementing asecurity model and enforcement thereof in a graphics subsystem of acomputing device.

2. Introduction

Graphics subsystems and operating systems generally allow externalapplications and plug-in components, often authored by third-partydevelopers (such as application programmers) and other not fullytrustworthy sources, to execute in their environments.

This often raises security concerns for the native system. If thethird-party component is poorly authored and thus has serious flaws,executing it within the operating system environment might cause seriousor fatal error conditions. If the third-party component is malignant(such as a virus), it might intentionally steal sensitive data orperform destructive operations. Some operating systems have no way toenforce protections against poorly-written or malignant code, and soimplicitly “trust” this code, when it is run, to be well-written andbenign.

However, it is preferable that native systems take precautions againstexternal faulty or malicious code from harming or infiltrating thesystem. Many modern systems employ the use of processes as a unit ofprotection; for example, third-party components like applicationprograms might each run in their own process. In this model, code ispermitted to do anything it likes within its own process, but boundariesbetween processes are enforced at the hardware level. Each process isprovided by the system with a certain set of permissions to accessservices outside of that process, and code running within each processis limited to those external operations for which the process is grantedpermission. This use of processes as a unit of protection can be said tobe nearly ubiquitous among operating systems beyond a certain level ofcomplexity.

Implementing adequate safeguards using processes as the unit ofprotection requires both a policy and associated method for partitioningcode and components into processes, and a policy and associated methodfor granting those processes permissions.

A policy and method for partitioning code into processes is importantbecause this policy establishes the boundaries between components thatcan be controlled and manipulated by the system. If component A andcomponent B are in the same process, there are no guarantees the systemcan provide either component with that will ensure it is protected fromflaws or malice in the other. For example, code in component A couldaccess code or data in component B, getting access to component B'ssensitive data. Similarly, if component B requests and gains access toexternal resource C, the system has effectively given access to thatresource to all code running in the same process as component B. If,however, component A and component B are running in different processes,the system can both reliably protect one's code and data from flaws ormalicious code in the other, and can reliably grant a permission to oneof these components without granting it to the other.

One simple, common technique for protecting the system from flawed ormalicious action by components - and of protecting components fromflawed or malicious action on the part of other components - is to placeeach newly instantiated component into a separate process of its own.For example, for each application that is to be run, a new process iscreated and the application is placed in it, separated both from otherthird-party components and from system components by secure processboundaries. However, there is significant overhead associated with eachprocess. This includes both the memory and processing time associatedwith the creation and destruction of processes and the extra processingrequired in order to send messages across process boundaries as comparedto that required for communication within a process. Thus, creating aprocess for each new application can be highly inefficient. Often,components will have credentials that show themselves to be trustworthywith respect to certain system operations (such as a cryptographicsignature that could not realistically be duplicated by a maliciousimposter). In other cases, two or more components may be regarded astrustworthy with relation to each other but not with respect tosensitive system services (for example, component A and component Bmight both be cryptographically signed by the same third-party publisheror vendor, but this publisher is not necessarily trusted by the systemitself), and in this case it might be optimal to place both of thesecomponents into a single process. Partitioning these trustworthy objectseach into their own process can be very wasteful of system resources,and can lower the overall performance of the system.

A policy and method for granting permissions to processes is importantbecause code running within a process can only access resources externalto that process if the system grants it permission to do so. Ifpartitioning code into processes establishes the “rule” (i.e. such andsuch component can only access those other components available in thesame process), granting permissions to processes establishes the“exceptions” to that rule (i.e. except for these specific systemservices, which code running in that process has the permission to use).In many systems this is done using a central repository for storing allsecurity knowledge, access control data, and so on. For example, if asystem service needs to process a request it might ask the centralauthority if the requester has permission to access that service. Thisdesign requires significant centralized knowledge of all system-widesecurity policies, data and policy duplication between securedcomponents and the central authority that implements the policies, andconstant communication between the central authority and objects in thesystem, both of which are undesirable in a dynamic, scalable, opensystem.

Also, in most systems, such permissions are defined and tracked in astatic way with respect to processes. For example, in such a system acomponent would be designed to exist in its own dedicated process, andwill declare security constraints for that process rather than for thecomponent. In a system where components are partitioned more dynamicallyinto processes, it would be preferable to define security policies atthe component level. This would allow per-component information to beused to make good partitioning decisions, and would allow a network ofinteroperable components to define their security policies in adistributed fashion, eliminating much of the need for centralization andthe overhead associated with it.

What is needed in the art is a method by which components may bepartitioned into processes based on the security requirements of boththe system itself and of components running in it with relation to eachother, such that desired protections can be enforced while theinefficiencies associated with processes and crossing process boundariesare minimized. Furthermore, in an environment where this first methodexists and components are distributed into processes based on dynamiccriteria, what is required is a method allowing security policies to bedefined in a distributed manner by components running in the system,both to inform process partitioning decisions and to allow forapplication-specific security policies to be enforced in a lightweight,scalable manner.

SUMMARY OF THE INVENTION

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the methods, instruments and combinations particularly pointedout in the appended claims. These and other features of the presentinvention will become more fully apparent from the following descriptionand appended claims, or may be learned by the practice of the inventionas set forth herein.

The present invention addresses the needs in the prior art for animproved system and method for providing a security model for objectsand enforcement of the model in the graphics subsystem and operatingsystem of a computing device. The present invention comprises a system,method and computer-readable media that provide security and accesscontrol for objects and components using a capabilities model inconjunction with the use of object interfaces and enforcement ofsecurity using dynamic protection domains implemented using the processas a protection boundary around objects.

The method aspect of the invention relates to a uniform, streamlined,and flexible procedure for creating objects that contain their ownsecurity policies and are placed in protection domains when they areinstantiated based on their specific security needs. The method utilizesa process boundary as the primary security or protection boundary forenforcing the security model. The security model takes advantage of thefact that most object models allow objects to have interfaces. Anobject's interfaces are used to determine what caller objects arecapable of accessing. Thus, there is a mapping of an object'scapabilities to interfaces. An object determines what a caller object isentitled to based on the investigation by the caller object and of whatthe caller is aware. The caller's investigation determines what otheraspects of the object the caller is entitled to.

In one aspect of the present invention, a method for controlling accessto an object in an operating system of a computing device is described.An interface of a target object receives a call from an external objectwhich is aware of the existence of the interface. At the target object,it is determined whether the external object has access to otherinterfaces of the target object based on the first call. Access isgranted to other interfaces based on this determination.

In another aspect of the present invention a method for securing anobject in a computing device operating system is described. Accessconstraints for an object are determined. A protection domain having asecurity profile that corresponds to the access constraints of the firstobject are identified. The object is then placed in the protectiondomain.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 is a diagram showing two aspects of a graphics subsystemcomponent of an operating system for a mobile or handheld device inaccordance with a preferred embodiment of the present invention;

FIG. 2 is a diagram of a display of a mobile device having userinterface elements, a display server process, and a view hierarchy inaccordance with a preferred embodiment of the present invention;

FIGS. 3A and 3B are diagrams of a render stream object, a sample streamof commands, and render stream branching;

FIG. 4 is a diagram of display server components and their relationshipsto the view hierarchy and the physical screen in accordance with apreferred embodiment of the present invention;

FIG. 5 is a diagram of a view object and selected various interfaces forcommunicating with other views in accordance with a preferred embodimentof the present invention;

FIG. 6 is a flow diagram of a process of mapping capabilities tointerfaces in accordance with a preferred embodiment of the presentinvention;

FIG. 7 is a diagram illustrating objects in processes and conduitsbetween processes implementing dynamic protection domains;

FIG. 8 is a flow diagram of a process of instantiating a new object in adynamic protection domain; and

FIG. 9 is a block diagram of the basic components of a computing devicein accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Various embodiments of the invention are discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustration purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without parting from the spirit and scope of the invention.

The present invention provides for systems, methods andcomputer-readable media that function as a graphics subsystem of anoperating system intended for use primarily on mobile and handhelddevices, but also executable on any computing device as described in thefigures. Examples of other computing devices include notebook computers,tablets, various Internet appliances, and laptop and desktop computers.In a preferred embodiment, the graphics subsystem operates on a handheldmobile computing device such as a combination cellular phone and PDA.

FIG. 1 is a diagram showing two primary aspects of a graphics subsystem100 of an operating system 10 in a preferred embodiment of the presentinvention. The two aspects are a drawing (or rendering) model aspect 102and a transport aspect 104. Generally, a graphics subsystem is thecomponent of an operating system that interfaces with graphics anddisplay hardware, provides application and system software access tothat hardware and to graphics-related services, and potentiallymultiplexes access to graphics hardware between and among multipleapplications.

The drawing model aspect 102 defines a highly expressive drawinglanguage. It allows a graphics subsystem programmer to describe an imageusing primitive drawing commands, including path filling and stroking,and to apply modulations of color, blending, clipping and so on.Rendering is modeled explicitly as a definition of the value of eachpixel within a target area. The drawing language provides a small numberof drawing primitives to modify current pixel values, including twobasic types of primitives: parametric drawing operations (pathdefinition) and raster drawing operations (blitting). More complexrendering is accomplished by compositing multiple operations. Othercapabilities of the rendering model of the present invention include:arbitrary path filling, alpha blending, anti-aliasing, arbitrarytwo-dimensional and color-space transformations, linear color gradients,bitmap rendering with optional bilinear scaling, region-based clippingand general color modulation (from Boolean clipping to spatial colormodulation). Components of the drawing model can be removed forlower-end devices. For example, components can be removed in order tonot support general color modulation, anti-aliasing, or other suchoperations that are expensive to compute on low-powered hardware. On theother hand, the model can be configured to benefit from a fullthree-dimensional hardware accelerator. The drawing model aspect 102also defines a drawing API that is used by clients to express commandsin the drawing language.

Transport aspect 104 enables the transmission of drawing commands fromwhere they are expressed by calls to the drawing API, such as within aclient process, to where they are executed, typically within a serverprocess. Transport aspect 104 addresses asynchronous operational issues.For example, it addresses the issue of how a screen or displaycontrolled by a display server can multiplex drawing and update commandscoming from different client processes and optionally execute thecommands out of order if the display server determines that theresultant image would be identical.

Drawing commands originating from multiple simultaneous clients of adisplay server are often not strongly ordered, i.e., they can often beexecuted in a different order and obtain the same image as if they wereexecuted in the order specified by clients. For example, in a preferredembodiment transport aspect 104 and drawing model aspect 102 of graphicssubsystem 100 are responsible for ensuring that with drawing commandgroupings A, B, and C specified in the order A to B to C, wherein thecommands in C overlay an area drawn into by A and B draws into an areathat is not affected by either A or C, A must be executed before C but Bshould be permitted to draw at any time. This is very useful insituations where A, B and C originate from different client processesand the client responsible for A is slow, blocked or has crashed, andthe client responsible for B is ready to continue processing. Transportaspect 104 also enables a display server to communicate with adistributed hierarchy of views, wherein each view has partial orcomplete ownership of certain portions of the screen, i.e., the actualpixels in those portions of the display.

FIG. 2 is a diagram illustrating a display 204 of a mobile device, thedisplay having elements 204 a, 204 b, and 204 c, a display serverprocess 202, and a view hierarchy 206. Display server 202 processcontrols the graphical features of the user interface shown on screen204, that is, which elements are displayed and how they are displayed.Display server 202 communicates with a view object hierarchy 206comprised of numerous views arranged in a parent-child relationship witha root view 208 distinguishable from the other views in that it is theonly view directly communicated with by the display server. Transportaspect 104 enables display server 202 to multiplex drawing commandscoming from different views potentially distributed across differentclient processes, and execute them in the correct order or in an orderthe display server determines is appropriate.

Drawing commands are transported from client views to the display serverresponsible for graphical rendering utilizing objects that function asdelivery conduits. These objects, referred to as render streams, are afeature of transport aspect 104. FIG. 3A is a diagram of a render streamobject 302 and a sample stream of commands 304. Render stream 302transports commands 304 from one or more clients (such as views) in oneor more client processes to a display server in a server process. In apreferred embodiment, render stream 302 is an object instantiated bydisplay server 202 and performs as a one-way pipe that transportscommands from where they are expressed, in a client view, to where theyare executed, in the display server. The client view and display servercan be in different processes or can operate in the same processassuming proper security measures have been taken if necessary, or ifthe system components are known to be trustworthy. In a preferredembodiment, drawing commands expressed into a render stream are bufferedbefore being transported to the display server for greater efficiencywhen transporting across process boundaries. There can be numerousactive render streams from views to the display server.

All types of drawing commands can be transported in render stream 302.In a preferred embodiment, drawing commands, e.g., moveto, lineto,closepath, fill <color>, stroke<color>, and so on, resemble Postscriptcommands. In a preferred embodiment, render streams facilitatetransmission of commands or any other data, such as pixels, modulationdata, etc., in one direction. Commands that typically do not requiredirect responses are best suited to be transported utilizing renderstreams.

Drawing model aspect 102 can carry out its functions independent of anyrender stream. For example, if the destination for drawing commands islocal, such as to a bitmap, rather than to the screen of a handhelddevice, the drawing model does not need to utilize a render stream(although it may use other features of transport aspect 104). In caseswhere the drawing model operates independent of a render stream, thesame drawing model API is used. However, depending on the context,commands may be rendered immediately to a local surface, or may betransported to a display somewhere else.

In a preferred embodiment, drawing by client views occurs when they areasked by the display server to refresh the screen. This is done when aview, responsible for a certain area of pixels on the screen is invalidor ‘dirty’ or needs to be re-drawn for any reason, for example aftersome action or state change has occurred that changes the look of one ormore visible components, or that adds or removes views form thehierarchy. In response to an update event, views send drawing commandsto the display server so the server can change those pixels according tothese commands. In a preferred embodiment, this is the only mechanism bywhich a view may draw to the screen.

This sequence of events encompassing the request made by the displayserver and the resulting drawing that occurs by clients is referred toas an update cycle. The display server initiates such a cycle by sendingan update event to the root view, which will then distribute the eventthroughout the view hierarchy as needed to invoke views to draw,together composing the final image. Render streams are used during anupdate cycle to transport rendering commands from client views to thedisplay server when the server operates in a different process or devicefrom that of one or more of the client views, or when there are multiplesystems of views operating asynchronously with respect to one anotherand conjoined within the same view hierarchy. These conjoined systems ofviews are asynchronized with respect to one another by the use of viewlayout root objects, as detailed below.

The graphics subsystem of the present invention allows an update to beexecuted serially by each view synchronously following the drawing ofits predecessor in the hierarchy within a single system of views, or inparallel by multiple systems of views which operate asynchronously withrespect to one another. This is enabled in part by the ability of arender stream to branch. Branching is a procedure whereby an offshoot orbranched render stream is created and passed to a child view to draw atsome later point that the child chooses (i.e. asynchronously withrespect to the parent view performing the branching operation), whilethe original or parent render stream continues to be used synchronouslyto transport subsequent drawing commands expressed by the parent view.

FIG. 3B illustrates render stream branching. For example, a clientprocess encompassing one or more views in hierarchy 206 may have anapplication user interface it wants drawn on the screen. The displayserver ultimately controls what is displayed on the screen and clientviews have the information needed to describe the desired image, and sothe display server needs a render stream with which to receive drawingcommands from these views. In a preferred embodiment, the display serverinstantiates a render stream and passes it to root view 208 along withan update event, initiating an update cycle. The commands necessary todraw the application's imagery are divided into three sequences A, B,and C, and each sequence is generated by a subset of the viewscomprising the application. Sequence A is generated and placed into theoriginal render stream 306, after which render stream 308 is branchedfrom it and given to the subset of views that generate sequence B to beused to express and transport those commands. Following this, sequence Cis generated and placed into the original render stream 306. Renderstream 308 is thus branched from render stream 306 at a point aftercommands in group A has been expressed (though perhaps buffered and notnecessarily transported) but before the first command in group C hasbeen expressed. Data transported in render stream 306 includes commandsfrom sequence A, a token for render stream 308, and commands fromsequence C. Commands in render stream 308 are from sequence B., and thisrender stream uses TOKEN B to identify itself when returning drawingcommands to the display server.

Each act of branching creates a possibility of re-ordering by thedisplay server. Thus, in this scenario branching has created thepossibility that the commands in render stream 308 can executeconcurrently or out-of-order with commands in render stream 306. Actualparallel execution can be employed using multiple processors or hardwareaccelerators, or greater efficiency can be reached by re-orderingcommands sent to a single graphics accelerator. The display serverreceives these commands from render stream 306 and 308 in parallel anddecides the actual order in which the commands will be executed based onthe expressed order and on the dependencies between and among thecommands.

FIG. 4 is a diagram of display server components and their relationshipto the view hierarchy and the physical screen. The display server 202controls the screen and is the only entity with direct access to it. Thegraphics driver is divided into two components: a driver 402, whichprovides full access to graphics hardware registers and resides in theI/O subsystem or kernel of the host operating system, and a graphicsaccelerant 404, which resides in the display server 202 and providesmemory-mapped access to the frame buffer and access to any graphicsfunctions implemented by graphics acceleration hardware. The displayserver is comprised of the graphics accelerant, a low-level renderer 406(also known as mini-GL), which is responsible for region filling andpixel operations, and a high-level renderer 408 which provides memorybuffer management, drawing path manipulation such as stroking, renderingstate management, and so on.

The display server 202 has explicit knowledge of only one view, the rootview 208. From the display server perspective, root view 208 isresponsible for handling events (including input and update events) forthe entire screen. On simple devices the root view may in fact be theonly view. If there is a single process that uses only one view and nore-ordering of views, the complexity of the design collapses into asimple code path between the display server and view hierarchy, which ishighly efficient on weak hardware. On devices with more advancedhardware and user interfaces the root view distributes itsresponsibility for handled update and input events to a hierarchy ofviews.

FIG. 5 is a diagram of a basic view object 502, which has three separateinterfaces named IView 504, IViewParent 506, and IViewManager 508. Theview hierarchy operates by the interaction of parents and childrenwithin the hierarchy accessing these interfaces on one another. IView504 allows manipulation of the core state and properties of a view, aswell as allowing it to be added to another view as a child, such aschild view 510. IView 504 is the interface that a parent sees on itschildren. Input, update, layout and other event types are propagateddown the hierarchy from the display server to leaf views by each parentview making calls on its childrens' IView 504 interfaces, and thoseviews in turn (either synchronously or asynchronously) making calls ontheir own children's IView 504 interfaces, and so on. The IViewParent506 interface is the interface that a child view sees on its parent,such as parent view 512 and which it can use to propagate events up thehierarchy, such as invalidate events or requests for a layout to beperformed. IViewManager 508 is the interface that a child view would useon its parent to manipulate its siblings, or that a third-party piece ofcode would use to add or remove children to a view.

The loose coupling of the view hierarchy is enforced in part by thehiding of certain of these interfaces from a caller that has access tocertain others. For example, the default security policy for views(which can be overridden by each view as desired) is that a child viewwhich is initially given an IViewParent 506 interface for its parentwill not be able to convert that to an IView 504 interface. The viewitself stores state such as the spatial 2D transformation that shouldapply to that view's drawing, a reference to its parent, and so on.

A capability-like security model that establishes a peer-to-peer trustnetwork between and among a set of active objects is described in FIGS.6 and 7. The security model allows for each object in the system todeclare its own security policies, and for the trust network to beimplicitly and dynamically established by the application of each policyby each individual object.

Capability security models are based on a set of simple principles.Primary among those principles is the Principle of Least Authority,which states that if an object requires access only to resource (orcapability) A in order to perform its duties, it should be given accessonly to A, and not, for example, to arbitrary other capabilities like Band C. Additionally, if an object determines that it requires capabilityD, it must explicitly ask for D using another capability which permitsand may grant this request.

Many object models and object-oriented programming languages allow anobject defined using them to expose or publish one or more well-definedinterfaces that operate on it. Each interface that an object publishesdefines a set of messages that can be sent to the object or methods thatcan be called on it. In most interface-based object models, a clientthat wishes to make use of an object must first obtain a reference to aninterface of that object by inspecting the object and requesting thedesired interface, and then make method calls on or send messages tothat interface. Such an interface is typically the smallest granularityat which access to the object is granted.

In a preferred embodiment of the present invention, security policiesare defined and implemented by requiring any request to an object for agiven interface to be made using an already-known well-defined interfaceof that object, by informing the object at the time of such request asto which interface the request was made using, by allowing each objectto customize which interfaces they publish based on—among otherfactors—which interface the request was made using, and by mapping eachobject interface to its own capability-like secure communication channelwhen that interface is referenced or used by an object within anotherprocess or device (in other words, when a method call or message passingis performed on an interface across a secure boundary).

When an object (the “caller” object) wishes to make a request for aninterface B of another object (the “callee” object), that request mustbe made using some interface A of the callee that the caller has alreadyobtained through some means. This interface A could, for example, havebeen provided to the caller at the time it was created by the creatingobject, or could have been requested by the caller in an interactionwith another object. The callee object will receive the request for B,and will be informed at this time that the request was made usinginterface A. Based on this knowledge, on whether the callee actuallyimplements interface B, and on any other policies the callee wishes todefine, the callee can decide whether or not to provide the caller withthe requested interface B.

In addition, other calls made on or messages exchanged using aninterface (i.e. those which do not perform interface inspectionrequests) can themselves return interfaces published by the calledobject or by any other object. In each such interaction—either explicitinterface inspection or the sharing by one object with another areference to the interface of a third—a trust network among a network ofpeer objects is progressively and dynamically defined. This trustnetwork defines the range of what operations are permissible by a givenobject. For example, if a caller object has a reference to interface Aof a callee object, it could easily obtain access (and thus should beconsidered as having access to) any other interfaces on the callee itcan obtain by making interface requests through interface A, as well asthose interfaces on other objects that the callee might have access toand might make available through A.

The decisions that each object makes as to how, when, and with whom toshare its own interfaces or those of another object are up to thespecific object implementation, and can be dependent on any number offactors that the object chooses to consider. In the preferred embodimentof the present invention, the primary or sole factor used to determinewhich interfaces of a callee can be successfully requested by a calleris simply which interface the request was made using. While otherfactors such as cryptographic signatures, password protection, and userverification may be used by any particular object to establish specialrules based on particular situational needs, using these types offactors would require a central authority to be contacted and forcertain tests to be performed on the caller to determine whether or notthe caller has the necessary permissions. If an object gets a call onone of its interfaces, the object knows that the calling object hasauthority or permission to make that call, by virtue of having had areference to that interface in the first place. In a preferredembodiment within any given object, the knowledge of which particularinterface was used to request another is all of the information that isneeded to determine which interfaces get exposed in response to thatrequest, and thus how the trust network is built. Thus, constantpermission checks with a central authority for each call to an objectinterface are not necessary.

Security policies can be established by dividing an object'sfunctionality into interfaces that define categories of services groupedby what level or type of permission is required to access the service.For example, an object can have an interface that grants minimal accessand can give this capability to objects that cannot necessarily be fullytrusted, and can provide other interfaces that grant full access to allcapabilities to other objects that can be trusted.

As shown in FIG. 5, in an exemplar of the preferred embodiment, agraphical view object has three interfaces: IViewManager, IViewParent,and IViewChild. A hierarchy of such views operates by the interaction ofparents and children within the hierarchy accessing these interfaces onone another.

The default security policy for views (which can be overridden by eachview object as desired) is that IViewManager and IViewParent (if evenimplemented by the object) are both exposed to any request made usingthe IView interface, but that IView is hidden from any requests madeusing the other two interfaces (i.e. a request for an IView interfacesusing either the IViewManager or IViewParent interfaces will fail), andthat IViewParent is hidden from IViewManager. In other words, a callerrequesting interfaces for the view using the IView interface will beable to obtain both IViewParent and IViewManager, a caller requestinginterfaces using IViewParent will be able to obtain IViewManager, and acaller requesting interfaces through IViewManager will see no additionalinterfaces.

Each of these interfaces grants a specific set of permissions to anyobject obtaining a reference to it, and this default view securitypolicy is designed around the assumption that a view essentially ownsits children and can manipulate them as desired, but that a child shouldnot in general be able to directly control or manipulate its parent. Aparent has an IView interface for each child, and thus can control eachchild completely because it can access all known interfaces of thechild. But because a child view is only given an IViewParent interfacefor its parent when it is added to the hierarchy, it is not able toobtain an IView interface for the parent, which would allow it, forexample, to move or resize its parent, or to obtain yet otherinformation such as a reference to its parent's parent. This gives thechild only indirect influence over views above it in the hierarchy, asprovided by the limited IViewParent interface. For a specific objectwith specific needs, a parent view could decide whether or not toprovide the IViewManager interface in response to requests made on theIViewParent interface, which would in effect be granting or denying toits children the permission to gain direct access to manipulate itssiblings. This permission might make sense in some situations and not inothers, and so each object could choose to override the default policyas it sees fit.

Abiding by this policy allows a view hierarchy to cross many processesand propagate messages up and down the hierarchy in a uniform waywithout the need of special interfaces, while maintaining security.

FIG. 6 is a flow diagram of a process for an object determining securityaccess based on an interface call in accordance with a preferredembodiment of the present invention. At step 602 a target objectreceives a call at one of its interfaces from an external object. Forexample, the target interface may have three interfaces A, B, and C,each granting varying degrees of access to the target object'sfunctions. Interface A granting the highest degree of access andinterface C, the lowest. At step 604 the target object determineswhether the external object is allowed access to other interfaces bychecking its own security policies. In a preferred embodiment, thetarget object does not check with a central authority storing securitydata for all objects in the system. If the external object is calling oninterface A, the target object may determine that the external objecthas access to interfaces B an C. At step 606 the target object grantsaccess to the external object to allow access to other interfaces asdetermined at step 604.

What is described above is how objects behave and define securitypolicies regardless of what processes they exist in. For example, thecaller and callee objects can be in the same or in different processes.The policy or pattern by which objects are distributed across processesdoes not have to be known at the time code is written or the timesecurity policies are defined. The code is written assuming that theimplicit security policies between objects as defined by interfaceinspection policies will be reliably enforced by the system.

However, what is described above only provides mechanisms for definingsecurity policies. There are various classes of methods of enforcingsuch a model, including memory protection and language-based security.In a preferred embodiment, one such method of enforcement separatesobjects that must be protected from one another into separate processes.

In a preferred embodiment of the present invention, when an object inone process obtains an interface on an object in a different process (onthe same device or on another), a secure conduit between those processesis established and associated with that interface reference. For eachsingle interface on a particular object in one process, a single secureconduit exists between it and another process if that other processcontains objects that hold a reference on that interface. This secureconduit is used to transmit messages and method calls on a particularinterface from one process to another, and to return any result valuesto the caller. This is shown in FIG. 7. Thus, if an object 702 in aprocess 704 has an interface 706, and a reference to interface 706 isheld by an object 708 in a process 710 and objects 712, 714, 716 inprocess 718, two secure conduits exist: one conduit 720 between process704 and process 710 and another conduit 722 between process 718 andprocess 704. All calls or interactions with a given interface on a givenobject from the same remote process will be routed through the samesecure conduit.

These secure conduits are created on-demand as needed, whenever aninterface is shared with a particular remote process for the first time.The use of these secure conduits allows an object to be assured thatwhen a request arrives from a remote process, that the caller isauthorized to have made the request by virtue of having had a referenceto the interface, and that this interface on which the request was madecan be reliably identified. A secure conduit is only created when aprocess boundary exists between two communicating objects, as shown bythe broken lines in FIG. 7. If an object wishes to make calls on anotherobject in the same process, that object is referred to and calleddirectly without the use of a secure conduit. This makes the case oflocal communication between objects very fast.

While the security policies established by the objects themselves (asdetailed above) are always in effect, separating objects into distinctprocesses—and thus forcing the use of secure conduits to be used toexchange messages, data and interface references between them—is areliable way to enforce those policies. The goal is to protect theobject from malicious or faulty code, and to protect existing objectsfrom it. But enforcement of security policies can have significantperformance and memory usage implications. For example, if each objectin the system were given its own process, the resulting overhead wouldbe unacceptable. Yet, in an enforcement scheme based on processes andimplemented using hardware memory protection, this is what would beneeded if strict enforcement of security policies was required for everyobject in the system. Therefore, it is desirable to only applyenforcement of these policies when such enforcement is deemed necessary.

There are various reasons that enforcement of security policies may bedeemed unnecessary. For example, if all of the components that areinteracting with one another within a network of objects were authoredby the same vendor, it is highly unlikely that they will be maliciouswith respect to one another, and thus they do not need to be protectedfrom one another. Another example is two or more otherwise unrelatedobjects with identical security constraints and permissions (such as twonormal third-party applications that do not deal with sensitive orprivate data). In both cases, clustering the set of objects into acommon process would greatly reduce the memory overhead required ascompared to having one process per object, and the objects themselveswould be able to interact very efficiently without the creation ofsecure conduits to route messages between interfaces. This separation isdone judiciously, for example, when it is not overridden by a blanket oftrust extended to all objects published by the same vendor.

In a preferred embodiment of the present invention, a security model isenforced selectively by allowing the system to allocate objects atcreation time into distinct domains referred to as dynamic protectiondomains. This is illustrated in FIG. 8. At step 802 a caller determinesthat it needs to instantiate a new object. An object instantiationfacility is provided in which a caller makes a request that an object beinstantiated or created as shown in step 804. The request provides thatthe object being instantiated be created within a dynamic protectiondomain which the system determines to be most appropriate. At step 806,an instantiation facility creates an object based on a variety ofsecurity factors such as security constraints and requirements declaredby active objects in the system, the system's own global securitypolicies, and any trade-offs that the system is willing to make, ofsecurity vs. performance and optimal resource utilization. At step 808the object is placed in an existing dynamic protection domain or a newprotection domain, implemented in a preferred embodiment by processes.The system may also create new dynamic protection domains if this isdeemed necessary, to host the newly created object.

The object that is returned from this instantiation facility may be areference to an interface on a remote object that was created in aremote protection domain (for example, if the newly created object needsto access sensitive data that the creator does not have permissions toaccess), or it might be a local object within the same process (forexample, if the newly created object is cryptographically signed by apublisher that the creator has declared it trusts). Because the creatoris using the interface abstraction facilities discussed above, it doesnot need to know or behave differently depending on whether theresulting object has been created locally or remotely. The constraints,policies and requirements used to make these decisions areimplementation specific, and can vary from device to device. In apreferred embodiment of the present invention, a dynamic protectiondomain is implemented as a process.

Objects are clustered into protection domains based on protectionpolicies, but are placed as “close” as possible to the caller or to adelegate that the caller designates while still obeying those policies.In other words, if an object can be created in the same process as thoseobjects that will be interacting with it without violating securityconsiderations, it will be.

In a preferred embodiment, in a view hierarchy, a parent view mayinstantiate a “plug-in” child view object without having prior knowledgeof what that component does or what vendor has provided it. Based on thesecurity constraints and policies of the parent, the parent's process,the system, and the child, the system can decide whether to load thechild component into the parent's process (which would allow thegreatest performance), to create a new process for the child to live in(which would provide the greatest protection), or to place the new childinto some other existing process that happens to fit the child'ssecurity needs and which contains no objects holding private information(which would provide a good level of security and robustness for theparent and the system while not requiring a wholly new process to serveonly a single child view object). This allows the view hierarchy, forexample, to be built dynamically out of cooperating pieces ofthird-party code without the hierarchy configuration being known by anyone component, but while still allowing protections to be maintainedbetween those components that express a need for such protections.

Inasmuch as one embodiment of the invention described above relates to ahardware device or system, the basic components associated with acomputing device are discussed below.

FIG. 9 and the related discussion are intended to provide a brief,general description of a suitable computing environment in which theinvention may be implemented. Although not required, the invention hasbeen described, at least in part, in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a personal computer or handheld computing device. Generally,program modules include routine programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat the invention may be practiced with other computer systemconfigurations, including handheld devices, multiprocessor systems,microprocessor-based or programmable consumer electronics, network PCs,minicomputers, mainframe computers, communication devices, cellularphones, tablets, and the like. The invention may also be practiced indistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network. Ina distributed computing environment, program modules may be located inboth local and remote memory storage devices.

With reference to FIG. 9, an exemplary system for implementing theinvention includes a general purpose computing device 9, including acentral processing unit (CPU) 120, a system memory 130, and a system bus110 that couples various system components including the system memory130 to the CPU 120. The system bus 110 may be any of several types ofbus structures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Thesystem memory 130 includes read only memory (ROM) 140 and random accessmemory (RAM) 150. A basic input/output (BIOS) contains the basic routinethat helps to transfer information between elements within the personalcomputer 9, such as during start-up, is stored in ROM 140. The computingdevice 9 further includes a storage device such as a hard disk drive 160for reading from and writing data. This storage device may be a magneticdisk drive for reading from or writing to removable magnetic disk or anoptical disk drive for reading from or writing to a removable opticaldisk such as a CD ROM or other optical media. The drives and theassociated computer-readable media provide nonvolatile storage ofcomputer readable instructions, data structures, program modules andother data for the computing device 9.

Although the exemplary environment described herein employs the harddisk, the removable magnetic disk and the removable optical disk, itshould be appreciated by those skilled in the art that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memory (RAM), read onlymemory (ROM), and the like, may also be used in the exemplary operatingenvironment.

FIG. 9 also shows an input device 160 and an output device 170communicating with the bus 110. The input device 160 operates as asource for multi-media data or other data and the output device 170comprises a display, speakers or a combination of components as adestination for multi-media data. The device 170 may also represent arecording device that receives and records data from a source device 160such as a video camcorder. A communications interface 180 may alsoprovide communication means with the computing device 9.

As can be appreciated, the above description of hardware components isonly provided as illustrative. For example, the basic components maydiffer between a desktop computer and a handheld or portable computingdevice. Those of skill in the art would understand how to modify oradjust the basic hardware components based on the particular hardwaredevice (or group of networked computing devices) upon which the presentinvention is practiced.

Embodiments within the scope of the present invention may also includecomputer-readable media for carrying or having computer-executableinstructions or data structures stored thereon. Such computer-readablemedia can be any available media that can be accessed by a generalpurpose or special purpose computer. By way of example, and notlimitation, such computer-readable media can comprise RAM, ROM, EEPROM,CD-ROM or other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium which can be used to carryor store desired program code means in the form of computer-executableinstructions or data structures. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or combination thereof) to a computer, the computerproperly views the connection as a computer-readable medium. Thus, anysuch connection is properly termed a computer-readable medium.Combinations of the above should also be included within the scope ofthe computer-readable media.

Computer-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Computer-executable instructions also includeprogram modules that are executed by computers in stand-alone or networkenvironments. Generally, program modules include routines, programs,objects, components, and data structures, etc. that perform particulartasks or implement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated data structures represents examples ofcorresponding acts for implementing the functions described in suchsteps.

Those of skill in the art will appreciate that other embodiments of theinvention may be practiced in network computing environments with manytypes of computer system configurations, including personal computers,hand-held devices, multi-processor systems, microprocessor-based orprogrammable consumer electronics, network PCs, minicomputers, mainframecomputers, and the like. Embodiments may also be practiced indistributed computing environments where tasks are performed by localand remote processing devices that are linked (either by hardwiredlinks, wireless links, or by a combination thereof) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

Although the above description may contain specific details, they shouldnot be construed as limiting the claims in any way. Other configurationsof the described embodiments of the invention are part of the scope ofthis invention. For example, objects may use features other thaninterfaces of the object model to which capabilities can be matched. Inanother example, a protection domain can be defined by a component ofthe system other than a process, such as memory protection orlanguage-based security. Accordingly, the appended claims and theirlegal equivalents should only define the invention, rather than anyspecific examples given.

1. A method for controlling access to an object in an operating system,the method comprising: receiving a call from an external object to afirst interface of a target object; at the target object, determiningwhether the external object has access to other interfaces of the targetobject based on the call to the first interface; and granting access tothe other interfaces according to the determination.
 2. A method asrecited in claim 1, wherein determining whether the external object hasaccess to other interfaces of the target object further comprisesexamining a security policy contained within the target object.
 3. Amethod as recited in claim 2, wherein the security policy is containedentirely within the target object.
 4. A method as recited in claim 1,further comprising determining whether the external object and thetarget object operate in the same process.
 5. A method as recited inclaim 1, wherein determining whether the external object has access toother interfaces of the target object further comprises: identifyingother interfaces of the target object that can be accessed when thefirst interface is being requested by the external object.
 6. A methodas recited in claim 1, further comprising determining a first process ofthe target object.
 7. A method as recited in claim 6, further comprisingdetermining a second process of the external object.
 8. A method asrecited in claim 7, further comprising performing a cross-processcommunication between the target object and the external object.
 9. Amethod as recited in claim 1, further comprising securing a channel foreach interface of the target object.
 10. A method as recited in claim 1,wherein determining whether the external object has access to otherinterfaces of the target object further comprises analyzing accessconstraints within the target object.
 11. A method as recited in claim1, further comprising analyzing interface access data stored within thetarget object.
 12. A method as recited in claim 1, further comprisingdetermining whether the target object and the external object are in asame protection domain.
 13. A method as recited in claim 12, wherein theprotection domain is a process.
 14. A method as recited in claim 1,wherein the target object sets its own security policy.
 15. A method asrecited in claim 1, wherein determining whether the external object hasaccess to other interfaces further comprises determining thecapabilities of the external object.
 15. A method as recited in claim14, further comprising mapping the capabilities of the external objectto the interfaces of the target object.
 16. A method as recited in claim1, wherein the target object and the external object are created using asame methodology.
 17. A method as recited in claim 1, wherein the targetobject and the external object are views in a view hierarchy.
 18. Amethod as recited in claim 17, wherein a view has a parent callinginterface, a child calling interface, and a child managing interface.19. A system that controls access to an object in an operating system,the system comprising: a module configured to receive a call from anexternal object to a first interface of a target object; a moduleconfigured to determining whether the external object has access toother interfaces of the target object based on the call received at thefirst interface; and a module configured to grant access to the otherinterfaces according to the determination.
 20. A system that controlsaccess to an object in an operating system, the system comprising: meansfor receiving a call from an external object to a first interface of atarget object; means for determining, at the target object, whether theexternal object has access to other interfaces of the target objectbased on the call to the first interface; and means for granting accessto the other interfaces according to the determination.
 21. A computerreadable medium storing instructions for controlling a computer deviceto control access to an object in an operating system, the instructionscomprising: receiving a call from an external object to a firstinterface of a target object; at the target object, determining whetherthe external object has access to other interfaces of the target objectbased on the call to the first interface; and granting access to theother interfaces according to the determination.
 22. A method forsecuring an object in a computing device operating system, the methodcomprising: determining one or more access constraints of a firstobject; identifying a protection domain that has a security profile thatcorresponds to the one or more access constraints of the first object;and placing the first object in the protection domain.
 23. A method asrecited in claim 22, further comprising creating the first object and asecond object using the same methodology.
 24. A method as recited inclaim 23, wherein the first object and the second object can communicatetransparently across two or more protection domains.
 25. A method asrecited in claim 22, wherein the protection domain is a process.
 26. Amethod as recited in claim 22, further comprising creating anobject-to-object security model wherein security constraints for anobject are contained within the object.
 27. A method as recited in claim22, wherein identifying a protection domain further comprises attemptingto identify a protection domain that is local relative to the firstobject.
 28. A method as recited in claim 22, further comprising creatinga process based on security requirements of the operating system.
 28. Amethod as recited in claim 28, further comprising clustering objects inthe process based on security policies of the objects.
 29. A system forsecuring an object in a computing device operating system, the systemcomprising: means for determining one or more access constraints of afirst object; means for identifying a protection domain that has asecurity profile that corresponds to the one or more access constraintsof the first object; and means for placing the first object in theprotection domain.